In the book "Zen and the Art of Motorcycle Maintenance", Robert Pirsig's protagonist, "Phaedrus" is exploring the idea of Quality. At one point he reaches the statement: "Quality is what you like".
In Agile Software Development � as in many other realms � we consider the notion of "value". We make decisions about what to do, or what not to do, based on "value". We do things sooner if they are of higher "value", later if their "value" is lower. What do we mean by value?
Value is what you like.
You may at first feel that this statement is too Zen, or that it has no meaning at all. Let's explore here what we might mean by value, and how we work with it. My aim is to help you see that value is in fact, what you like.
Agile methods ask us to choose the order in which we do things based on "value". Sometimes we might say "business value", or "customer value", as if these qualifications helped. In a way, they do help, because they may cause us to think about things we value in terms of "good for the business" or "good for the customer". But these are far from the only kinds of value we might consider. Let's look at just a few more.
We might be choosing a strategic direction for our product. We decide that we need information about what users would prefer, so we produce some prototypes of the product and show them to potential users.
We value information.
Our product might be aimed at saving lives: perhaps it helps us ship vaccines around the world quickly. We decide to choose our next features based on the number of lives saved by that features.
We value human life.
Our company might be running out of cash. We decide to get some venture capital and to produce a sample product quickly, to show to the would-be investors.
We value capital. We value company survival. We value the ability to help the customers we may someday have if we stay in business.
Our product might be too slow. Customers are using alternatives because they do not like the speed of our product. We decide to defer features to speed up the software.
We value product speed.
Our progress might be too slow, taking too long to get things done. We decide to defer features to clean up the software, so that we can develop faster.
We value rapid progress.
Our product might display funny cat pictures. Our purpose might be to give people a smile, a bit of happiness in their day.
We value people's happiness.
We value joy. We value creativity. We value collaboration. We value money. We value revenue. We value the ability to keep working. We value the ability to be with people we care about, doing things we care about. We value human life, or even kitty life.
These are just a few of the things that make up value. The problem of the "Product Owner", of management, of all the people who decide what we should do next, is to look deeply at the many things we value, and to choose a sequence of development that gives us the best possible result in return for our time, money, and effort in building our product.
It would be nice if it were easier. It would be nice if we could just say "Value is revenue over the next 90 days", or "Value is what the VP of Sales wants". It might even work for some people, some companies, sometimes. But no such definition will work for everyone, and in my opinion, it won't work very well for anyone. If we are to survive as a company or as individuals, we need to look deeply at value, and to choose the things that matter, among all the things we might do.
Choosing value is choosing what matters, to you.
